Service modeling and virtualization

ABSTRACT

The systems and methods described herein can be used to provide virtual service environments. In one embodiment, a virtual service model is generated by detecting one or more transactions, each of which includes a request sent from a requester to a software service and a response sent from the software service to the requester; storing information describing the detected transactions in a virtual service model, where the information describing each transaction includes information identifying a command included in the request and information identifying a response attribute included in the response; and generating information describing an unknown transaction, where the information describing the unknown transaction includes information identifying a first command and information identifying a first response attribute. The first command and the first response attribute are copies of a corresponding command and a corresponding response attribute associated with a corresponding one of the detected transactions.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation and claims the benefit of priorityunder 35 U.S.C. §120 of U.S. application Ser. No. 13/341,650 filed onDec. 30, 2011 and entitled “Service Modeling and Virtualization”, whichapplication is a continuation of U.S. patent application Ser. No.12/242,783, filed Sep. 30, 2008, now issued as U.S. Pat. No. 8,112,262and entitled “Service Modeling and Virtualization”, naming John J.Michelsen as inventor. The disclosures of the prior applications areconsidered part of and are incorporated by reference in the disclosureof this application.

FIELD OF THE INVENTION

This invention relates to testing and, more particularly, to systems fortesting software that depends on and/or interacts with a constrainedservice that may not always be available for use during testing.

DESCRIPTION OF RELATED ART

As software becomes more sophisticated, it becomes more difficult toquickly and easily perform thorough software testing. One suchdifficulty arises when software testing involves testing the ability ofa program or application under test to interact with a constrainedsoftware resource, such as a database, metered partner service, or thelike. For example, an airline may be reluctant to test a new reservationapplication against the airline's live production database in order toavoid negatively impacting (e.g., in terms of database response time)actual consumer transactions that will be taking place at the same timeas testing. Similarly, in order to reduce costs, a financial institutionmay wish to minimize interactions between a new credit card applicationsystem and a partner service due to per-transaction fees, such as thosethat are charged for each credit check, charged by the partner service.In yet another example, the constrained service may still be indevelopment and thus not yet available to interact with the applicationunder test. As the above examples show, it is desirable to be able totest the application under test in a manner that avoids interacting withthe actual constrained service, while also obtaining test results thatindicate whether the application under test will ultimately be able toproperly interact with the constrained service.

BRIEF DESCRIPTION OF THE DRAWINGS

A more complete understanding of the present invention may be acquiredby referring to the following description and the accompanying drawings,in which like reference numbers indicate like features.

FIG. 1 is a block diagram of a system that generates a model of aservice, according to one embodiment of the present invention.

FIG. 2 shows information that can be maintained as part of a model of aservice, according to one embodiment of the present invention.

FIG. 3 is a flowchart of a method of generating a model of a service,according to one embodiment of the present invention.

FIG. 4 is a block diagram of a system that presents a virtual databaseservice, according to one embodiment of the present invention.

FIG. 5 is a flowchart of a method of presenting a virtual service,according to one embodiment of the present invention.

FIG. 6 is an illustration of a data model that can be used to storeinformation representing both stateful and stateless transactions,according to one embodiment of the present invention.

FIG. 7A shows an example of several stateful conversations that can beobserved and recorded by a service model generator, according to oneembodiment of the present invention.

FIG. 7B is an example of how several stateful conversations can bemerged into a single conversation, according to one embodiment of thepresent invention.

FIG. 8 is a block diagram of software that can be stored on a testingclient, according to one embodiment of the present invention.

FIG. 9 is a block diagram of software that can be stored on a testingserver, according to one embodiment of the present invention.

While the invention is susceptible to various modifications andalternative forms, specific embodiments of the invention are provided asexamples in the drawings and detailed description. It should beunderstood that the drawings and detailed description are not intendedto limit the invention to the particular form disclosed. Instead, theintention is to cover all modifications, equivalents and alternativesfalling within the spirit and scope of the invention as defined by theappended claims.

DETAILED DESCRIPTION

Various embodiments of the systems and methods described herein can beused to provide virtual service environments. These virtual serviceenvironments can be used for various purposes, including development,testing, load testing, integration testing, and training. In manysituations, the services to virtualize within virtual serviceenvironments can be identified during the software design phase, andthen the identified services can be virtualized and implemented withinvirtual service environments during the development phase. The virtualservice environments can then be used throughout the development andtesting phases.

The virtual service environments operate to present one or more virtualservices. Each virtual service responds to requests in a manner that isstructurally consistent with the service being virtualized. Providingvirtual services allows an application (e.g., an application under testor an application being used for training purposes) to interact with avirtualized representation of a software service that might nototherwise be readily available (e.g., due to constraints associated withthat software service) for testing or training purposes.

FIG. 1 is a block diagram of a system that generates a model of asoftware service. This system includes a requester 10, a service modelgenerator 20, and software service 30. In many embodiments, thesecomponents are each implemented in software that is executing on acomputing device (e.g., a personal computer, server, personal digitalassistant, telephone, or the like). The components shown in FIG. 1 canall be implemented on the same computing device. However, in manyembodiments, at least some of these components (or portions thereof)will be implemented on different computing devices, all or some of whichcan be coupled via one or more networks (e.g., a local area network,storage area network, and/or wide area network such as the Internet).

Service 30 can be any of a variety of different services and can beimplemented as any one or more of a variety of software components. Forexample, service 30 can be a database server that is configured torespond to requests to access information stored in a database.Alternatively, service 30 can be a web service (e.g., having aninterface defined by a web service definition language (WSDL) file), aweb site (e.g., as implemented by one or more web pages provided by aweb server), a legacy application operating on a mainframe, a dataservice, an order manager, a transactional data store, an enterpriseresource planning (ERP) system, an enterprise application integration(EAI) system, or the like. Service 30 can be implemented as an object orother component (e.g., an enterprise service bus (ESB) construct, anEnterprise JavaBean (EJB), a web component such as a JavaServer Pages(JSP) page or Java servlet component, other standalone Java component,or Java applet), as an application that includes any of thepreviously-mentioned components, or the like.

Requester 10 can similarly be implemented as any of a variety ofdifferent software components (or a combination of such components). Insome embodiments, there may be multiple independent requesters presentand generating requests at substantially the same time. In suchembodiments, service model generator 20 can detect requests beinggenerated by more than one requester, as well as the responses providedin response to those different requesters' requests.

As shown in FIG. 1, requester 10 generates a request, which is sent toservice 30. In response to receiving the request, service 30 generates aresponse and returns the response to requester 10. Service modelgenerator 20 is coupled (e.g., logically and/or physically) betweenrequester 10 and service 30, such that service model generator 20 caneffectively observe and record the traffic (i.e., the requests andresponses) being exchanged between requester 10 and service 30. Forrecording purposes, each request and its corresponding response aregrouped together, and a group containing a request and its correspondingresponse is referred to herein as a transaction. The recordedtransactions are stored as a service model 40, which will be used toimplement a virtual service environment that virtualizes service 30, aswill be described in more detail below with respect to FIGS. 4-6. Anexample of the information that can be stored as part of a service modelis provided in FIG. 2.

A user can also provide information describing transactions to servicemodel generator 20 for inclusion in service model 40. Such transactionsare referred to as user-supplied transactions, in contrast to theobserved transactions that are recorded in response to service modelgenerator 20 actually observing traffic being exchanged betweenrequester 10 and service 30.

Service model generator 20 can also generate and store informationidentifying one or more characteristics of the transactions. Suchinformation can include timing information identifying times at whichparticular requests and/or responses are detected or sent (e.g., inorder to identify the delay between when the request was detected and/orsent and when the associated response was detected and/or sent),information identifying current bandwidth usage of a network on whichthe traffic is being conveyed, information identifying current processorand/or memory usage on one or both of the computing devices implementingrequester 10 and service 30, and the like. Service model generator 20can store such information as part of service model 40.

Service model generator 20 is configured to detect and record traffic atthe network and/or communication protocol level. The particularcommunication protocol can vary according to the type of serviceprovided by service 30. Service model generator 20 can be configured toidentify requests and responses in each of a variety of differentprotocols and to extract and record the pertinent information from each.Thus, service model generator 20 can include configuration informationidentifying the basic structure of requests and responses for each ofseveral supported communication protocols. When generating service model40, service model generator 20 can access the appropriate configurationinformation in order to process the observed traffic. Depending upon theprotocol in use, requests can take the form of method calls to anobject, queue and topic-type messages (e.g., such as those used in Javamessaging service (JMS)), requests to access one or more web pages orweb services, database queries (e.g., to a structured query language(SQL) or Java database connectivity (JDBC) application programminginterface (API)), packets or other communications being sent to anetwork socket, and the like. Similarly, responses can include valuesgenerated by invoking a method of an object, responsive messages, webpages, data, state values (e.g., true or false), and the like.

In order to be able to detect and record traffic, service modelgenerator 20 is configured to logically insert itself into thecommunication pathway between requester 10 and service 30. In someembodiments, inserting service model generator 20 into the communicationpathway can also involve modifying requester 10 and/or software (e.g.,such as a driver) with which requester 10 interacts. For example, ifservice 30 is a web site or web service, service model generator 20 canbe configured as a web proxy or gateway, and requester 10 can bemodified to communicate with service 30 via the proxy or gatewayimplemented by service model generator 20. In such a situation, whenservice model generator 20 receives a request being sent to the proxy,service model generator 20 can generate and store informationidentifying the request and/or any desired request characteristics, andthen service model generator 20 can send the request to service 30. Ifneeded, service model generator 20 can modify the request before sendingthe request to service 30, so that the response generated by service 30will be returned to service model generator 20.

Various other configurations of service model generator 20 are possible.For example, if requester 10 and service 30 communicate via messaging,service model generator 20 can be configured to monitor the appropriatequeue(s) and topics for new messages being exchanged between requester10 and service 30. If service 30 is a database, the driver manager usedby requester 10 can be modified to indicate that service model generator20 is the driver for the database, such that requests sent to thedatabase will be provided to service model generator 20, and such thatresponses provided by the database will be returned to the requester viaservice model generator 20. If service 30 is an object, service modelgenerator 20 can be configured to intercept method calls to the object,generate information identifying those method calls to be stored as partof service model 40, and then to pass the method call to the objectbeing called. Similarly, service model generator 20 can interceptresponses from the object being called, store information identifyingthose responses as part of service model 40, and then provide thoseresponses to requester 20.

In some embodiments, the functionality provided by service modelgenerator 20 is distributed throughout a networked system. For example,a component of service model generator 20 that is configured to monitorrequests and responses sent according to a particular transport and/ordata communication protocol can be deployed on each client system thatincludes a requester 10 and/or each system that implements service 30.This component can be configured to communicate requests and responsesto another component of service model generator 20 that is configured tomanipulate such information and/or to store such information with aservice model 40.

Each request includes a command. The command can be the operationincluded in a SOAP message, the method being invoked on an object, adatabase command, a particular command or operation specified by acommunication protocol, or the like. Whenever service model generator 20detects a request, service model generator 20 can identify the commandcontained within that request (e.g., using configuration informationassociated with the type of protocol in use in order to identify whichportion of the request contains command information) and storeinformation identifying that command as part of service model 40.

Requests may also include attributes. For example, the request caninclude a command to perform a login operation as well as attributesthat include the user name and password to be used in the loginoperation. Accordingly, service model generator 20 can also parserequests in order to identify whether any attributes are present and, ifso, to extract and store information identifying those attributes. Thus,information identifying a request in service model 40 can includeinformation identifying a command as well as information identifying anyattributes present within the request.

Responses can include one or more attributes. Whenever service modelgenerator 20 detects a response, service model generator 20 parses thatresponse (e.g., using protocol-specific configuration information inorder to determine how to locate the attributes within the response).Service model generator 20 can then store each attribute detected withinthe response as part of the information identifying the response withinservice model 40.

When service model 40 is used to virtualize service 30 (as will beexplained in greater detail below), the virtualization process willinvolve comparing new requests generated by a requester to the requestinformation stored in service model 40. For example, if a new requestcontaining a particular command and attribute is received, service model40 can be searched for a matching request that contains the same commandand attribute. If a matching request is found, the virtualizationprocess returns the response (as identified by information stored inservice model 40) associated with the matching request to the requester.

In many situations, the requests provided to the virtualized servicewill not be exactly the same (i.e., containing the same request as wellas the same attribute(s)) as the requests identified in service model40. For example, a request provided to the virtualized service maycontain the same request but a different attribute or set of attributes.Accordingly, service model generator 20 is also configured to generateinformation usable to handle these requests and to store thatinformation as part of service model 40.

In order to generate this additional information, service modelgenerator 20 can identify each unique type of transaction that has beenobserved or specified by a user. For example, in some embodiments,service model generator 20 can be configured to identify alltransactions containing requests that specify the same command as beingof the same transaction type. Alternatively, service model generator 20can be configured to identify a set of transactions as being of the sametype if all of those transactions have requests that include the samecommand as well as the same number and type of attributes. Theparticular technique used to identify whether two or more transactionsare of the same type can be protocol specific, in some embodiments(e.g., service model generator 20 can use different techniques toclassify transactions depending upon the particular communicationprotocol being used between the requester and the service).

For each unique type of transaction included in service model 40 (e.g.,obtained either via observation of communication or via userspecification), service model generator 20 can generate additionalinformation that can be used to model service 30's response to a similartransaction of that type that contains an unknown attribute (i.e., anunknown attribute in this context is an attribute that was not observedas part of the monitored traffic or specified by a user during the modelbuilding process). For example, service model generator 20 can observeand record three different simple object access protocol (SOAP) requeststhat include the “getUser” command, and a user can specify a fourth“getUser” transaction for inclusion in service model 40. In response toidentifying that these transactions are the same type of transaction,service model generator 20 generates information describing a fifth“getUser” transaction that will be used to handle transactions of thattype that specify unknown attributes. This information for the fifthtransaction can include information identifying the request by the“getUser” command as well as information identifying the appropriatestructure, if any, of the request (e.g., by identifying the numberand/or type of attributes that can be included in the request, asdetermined from the other four transactions of that type). Theinformation describing the attributes of the request of this transactioncan be wildcard information or otherwise indicate that any unknownattribute(s) (i.e., attributes that are not the same as the attribute(s)in the observed and user-specified transactions) should match thisrequest's attribute information.

The information describing the fifth transaction also includesinformation identifying an appropriate response. In one embodiment,service model generator 20 generates this response information by simplycopying the response portion of the information describing one of theother four “getUser” transactions into the information describing theresponse portion of the fifth transaction. Service model generator 20can also or alternatively prompt a user to select the particulartransaction from which this response information should be copied.

Similarly, service model generator 20 can also generate informationdescribing a transaction that is used to model service 30's response toan unknown request (i.e., an unknown request in this context is arequest that contains a command that was not observed as part of themonitored traffic or specified by a user during the model buildingprocess). The request portion of this generated information can indicate(e.g., through the use of a wildcard command identifier) that allunknown types of requests that are not otherwise identified in servicemodel 40 should match this request. The response portion of thegenerated information can include an appropriate response. In someembodiments, the response is protocol-specific and can be obtained, forexample, from protocol-specific configuration information accessed byservice model generator 20. Alternatively, service model generator 20can prompt a user for the appropriate response to include in thistransaction.

In some embodiments, service model generator 20 can provide (orotherwise be configured via) a user interface (e.g., such as userinterface 480 of FIG. 4) that allows a user to configure service modelgenerator 20 to generate a particular service model. Such a userinterface can be a graphical user interface, command line interface, orthe like.

The configuration process for service model generator 20 can involve theuser selecting, via the user interface, the particular service 30 to bemodeled. As part of the configuration process, the user can be promptedto enter information identifying a specific service to be modeled (e.g.,service 30), as well as information identifying or indicating theprotocol(s) used to communicate with the identified service. Forexample, the user can identify a specific service by indicating thenetwork port used to communicate with that service, as well as thathyper text transfer protocol (HTTP) and SOAP are used to communicatewith that service. In response to this information being provided,service model generator 20 can insert itself in between the requesterand the service to be modeled. For example, an instance of anobservation module (not shown) that is configured to obtain request andresponse information for the specified transport and/or datacommunication protocols can be instantiated. This observation module ispart of service model generator 20 and performs the functions needed toobtain information describing the requests generated by the requesterand the corresponding responses generated by the service.

Service model generator 20 can also provide a user interface thatincludes one or more controls that allow a user to configure, start, andstop the model building process. Another control can allow a user tosave a model generated by service model generator 20. Yet anothercontrol can allow a user to modify a model generated by service modelgenerator 20 (e.g., a user can be allowed to modify or delete all orsome of the information generated by service model generator 20).Similarly, a user can be allowed to modify a model by adding additionalinformation (e.g., identifying new types of requests and associatedresponses, identifying new attributes for a particular type of requestsand associated responses, and/or identifying responses to be used forunknown requests).

Thus, service model generator 20 can begin and end the model buildingprocess in response to user input provided at the time that modelingshould begin and end. Alternatively, instead of selecting a “start” orstop” option, the user can specify a time and/or conditions under whichmodel building should begin, as well as a time and/or conditions underwhich model building should end. For example, a user can specify thatmodel building should begin at 1:00 AM on a particular date, andcontinue until 3000 transactions have been recorded. Similarly, a usercan specify that model building should begin when a particular type ofrequest is detected, and continue until the user selects to end themodel building process.

Furthermore, the model building process can be restarted. For example, auser can cause service model generator 20 to generate a model of aparticular service. At a future point in time, the user can restart themodel building process for the same service, causing service modelgenerator 20 to generate additional information to include in theservice model for that service. Similarly, a user may select to edit anexisting service model in order to add additional virtual functionality(e.g., in the form of new types of transactions and/or additionaltransactions of an existing type) to the model.

In some situations, instead of creating at least a portion of a modelbased upon actual observed traffic, service model generator 20 cancreate a model based only upon user input specifying particulartransactions (information describing additional observed transactionscould be added at a later time). For example, if such information is notalready available, service model generator 20 can prompt a user forinformation identifying the service to be modeled, as well asinformation indicating the protocol used to communicate with the serviceto be modeled. Service model generator 20 can then prompt the user forappropriate information (e.g., given the type of service being modeledand the communication protocol(s) used to communicate with that service)identifying one or more transactions. This information can includeinformation identifying a request (e.g., by identifying the commandcontained within that request, as well as any attributes provided aspart of that request) and a corresponding response (e.g., by identifyingone or more attributes contained within the response), as well asinformation identifying a characteristic of that request and/orresponse. In situations in which service 30 is not available (e.g.,because service 30 is still being developed), all of the transactionsidentified in service model 40 can be obtained via user input instead ofvia traffic observation.

In one embodiment, a user can specify multiple transactions at once. Forexample, when prompted, a user can select a file (e.g., a spreadsheetfile) that contains information describing many different transactions.Such a file can be, for example, a production log that describes theactivity taking place in a production system during a normal period ofoperation. In response to the user specifying the file, service modelgenerator 20 can access the file, extract the relevant information, andstore the extracted information in the model. In some embodiments,service model generator 20 can access an appropriate configuration filethat indicates how particular fields in the production log (or otherfile specified by the user) map to the different types of informationmaintained in the service model (e.g., the particular configuration fileto access can be specific to the service, the protocol(s) used tocommunicate with the service, or the like).

As noted above, a user can also modify the information describing one ormore observed transactions. In some embodiments, a user can relax thematching criteria associated with a transaction. For example, anobserved request can include a command requesting for flight informationfrom a particular origination city to a particular destination city, andthe virtual service model may default to matching only requests thatinclude the same command and attributes. A user can select to modify theinformation describing this command and can replace one or more of therequest attributes with special values (e.g., wildcard values) and/orselect a matching setting (e.g., specifying exact matching, regularexpressions, “starts with” matching, “contains” matching, or the like)for one or more particular request attributes. Thus, the user couldmodify the transaction requesting flight information to indicate thatall requests for flight information that include the same destinationcity attribute as the observed transaction should match the observedtransaction, regardless of whether such requests also specify the sameorigination city as the observed transaction. Users can also modifyinformation describing observed transactions in order to replaceobserved attributes with user-specified attributes and the like.

In many situations, transactions are stateless, such that eachtransaction is independent of any transactions that have taken placebeforehand. In other words, for a stateless transaction, service 30 willgenerate the same response to a given request, regardless of whether anyother transactions have already been performed. In such situations,service model generator 20 generates information identifying eachobserved transaction in the same manner, regardless of whether any otherprior transactions have been observed and regardless of the attributesand commands contained within such prior transactions.

In other situations, transactions are stateful, such that the responseincluded in a given transaction may differ depending upon whattransaction or transactions have already been performed. In thesesituations, service model generator 20 is configured to generateadditional state information for each transaction. This additional stateinformation identifies the preceding transaction (the state informationfor the preceding transaction can also be modified to identify thesubsequent transaction). More information regarding statefultransactions is provided in the discussion of FIG. 6.

FIG. 2 shows information that can be maintained as part of a model of aservice. Such a model can be generated by a service model generator suchas the one shown in FIG. 1. In this example, service model 40 includes arow for each of several transactions. Each row of service model 40identifies a command, zero or more attributes, zero or morecharacteristics, and one or more response attributes. This service modelcan be stored in a spreadsheet, table, database, or any other datastructure.

In this example, transaction 201(A) is an observed transaction. In otherwords, transaction 201(A) is a transaction that actually occurredbetween a requester and the service being modeled, as detected by aservice model generator. The information describing transaction 201(A)includes request information, which includes command 211 and zero ormore observed attributes 221(1). The information describing transaction201(A) also includes response information 241(1) describing the observedresponse that corresponds to the observed request. This responseinformation 241(1) can also include one or more attributes. Observedcharacteristics 231(1) can include zero of more observed characteristicsof transaction 201(A). These observed characteristics can include timinginformation describing when the request and/or response were observed orthe like, as described above.

Like transaction 201(A), transaction 201(B) is a transaction thatactually occurred (i.e., an observed transaction). Transaction 201(B) isof the same transaction type as transaction 201(A), since bothtransactions included a request that contained command 211. Transaction201(B) is described by observed attributes 221(2) (which can have valuesthat differ from those attributes observed in the request of transaction201(A)), observed characteristics 231(2) (which can again differ fromthose observed for transaction 201(A)), and observed response 241(2)(which can also have a value that differs from the response observed fortransaction 201(A)).

In this example, information describing n (an integer number) knowntransactions of the same type as transactions 201(A) and 201(B) isstored in service model 40. These known transactions are transactionsthat were either observed or specified by a user. As part of the modelbuilding process, information describing an n+1th transaction of thesame type has been added to service model 40 by the service modelgenerator. This n+1th transaction, labeled transaction 201(n+1),describes an “unknown” transaction of a known type of transaction. Suchan unknown transactions is of a known type because it has the samecommand, command 211, as the other transactions of this type. However,unlike the other known transactions of this type, unknown transaction201(n+1) can be used to respond to requests containing command 211 and“unknown” attributes that do not match those known (i.e., eitherobserved or user-specified) attributes stored for transactions201(A)-201(n) (not shown). The information describing transaction201(n+1) thus includes information (e.g., wildcard information)identifying unknown attributes 221(n+1), such that any request thatincludes command 211 and an attribute that does not match the observedattributes stored for the actual transactions (e.g., such astransactions 201(A) and 201(B)) will match the request information fortransaction 201(n+1).

The information describing transaction 221(n+1) also includes defaultcharacteristics 231(n+1) and default response 241(n+1). These defaultvalues can be copied from the corresponding fields of an actual responseof the same type. In some embodiments, the service model generatorprompts a user to select the actual transaction from which these valuesshould be copied. Alternatively, a user can be prompted to enter thesevalues directly.

Information describing another set of transactions of a different typeis also stored within service model 40. As shown, m+1 transactions,including transaction 202(A), 202(B), and 202(m+1) of a type oftransaction in which the request includes command 212 are stored inservice model 40. Like transactions 201(A) and 201(B), transaction202(A) is an observed transaction, and thus the information describingthis transaction includes the observed command 212, observed attributes222(1) (if any), observed characteristics 232(1) (if any), and observedresponse 242(1).

In contrast, transaction 202(B) is a user-specified transaction. Thistransaction was thus not observed and did not necessarily ever evenoccur. Instead, a user entered the information describing thistransaction via a user interface. The information describing transaction202(B) includes command 212, zero or more user-specified attributes222(2), zero or more user-specified characteristics 232(2), and auser-specified response 242(2). In some embodiments, the user isprompted for entirely new information for each of these user-specifiedfields. In other embodiments, the user can be allowed to select anexisting field (e.g., of another user-specified transaction or of anobserved transaction) to copy into one or more of these fields. It isnoted that a user can also create a user-specified transaction bymodifying information describing an actual transaction. As FIG. 2 shows,user-supplied transaction information can be stored in the same model astransaction information captured by observing actual traffic exchangedbetween a requester and the service being modeled.

A final transaction, 202(m+1), is an unknown transaction. Theinformation describing transaction 202(m+1) was added to service model40 after m (an integer number, which does not necessarily have the samevalue as n) known transactions were described by the model. Theinformation describing this unknown transaction 202(m+1) can be used tohandle requests of the same type (e.g., containing command 212) thatspecify unknown attributes. Accordingly, the information describingtransaction 202(m+1) includes command 212, unknown attributes 222(m+1)(i.e., attribute information that will match any attributes notidentified in the known attributes stored for the other m transactionsof this type), default characteristics 232(m+1), and default response242(m+1).

A final transaction 203 is also described in service model 40.Transaction 203 is an unknown transaction of unknown type. In otherwords, the information describing this transaction can be used torespond to any request of a type not already described by another row ofservice model 40. Accordingly, a request containing a command other thancommands 211 and 212 could be responded to using the informationdescribing transaction 203.

As shown, the information describing transaction 203 includes unknowncommand information 213, which is configured to match any command notalready specified in service model 40, unknown attribute information223, which is configured to match all attributes (if any) associatedwith unknown commands, default characteristics 233, and a defaultresponse 243. As with the default characteristics and responsesassociated with unknown transactions of known type, transaction 203'sdefault characteristics and response can be user-specified.

FIG. 3 is a flowchart of a method of generating a model of a service.This method can be performed by a service model generator such as thatshown in FIG. 1 in order to generate a service model like that shown inFIG. 2. The method is performed in response to model building beingenabled, either in response to direct input of a start command (e.g., bya user selecting a start button in a graphical user interface) or inresponse to occurrence of a trigger (e.g., a prespecified time and/ordate, or the occurrence of a prespecified event or series of events).

The method begins at 300, where a service model generator determineswhether a request has been detected. As noted above, detection of arequest can vary depending upon the particular transport and/or dataprotocols in use between the requester(s) and the service being modeled.For example, detection of a request can involve monitoring a queue,intercepting method calls to an object, intercepting requests being sentto a web server or database application, or the like.

If a request is detected, information identifying the observed request(e.g., information describing the command included in the request, theattribute(s) included in the request, if any, and information describingone or more characteristics of and/or associated with the request, ifdesired) and the associated response (e.g., information describing theattribute(s) included in the response, as well as information describingone or more characteristics of and/or associated with the response, ifdesired) is stored as part of the service model, as indicated at 305.

Operations 300 and 305 can repeat indefinitely, until a user selects toend the model building process (or at least the portion thereof thatgenerates information describing observed transactions) or untilprespecified ending conditions are met.

At 310, a determination is made as to whether user input specifying arequest has been received. This determination can be made, for example,by detecting whether a user has selected an option (in a user interface)to add additional transactions to and/or modify existing transactions inthe service model.

If user input specifying a request has been received, informationidentifying the user-specified request (e.g., information describing acommand and/or the attribute(s) included in the request, if any, andinformation describing one or more characteristics of and/or associatedwith the request, if desired) and the associated user-specified response(e.g., information describing the attribute(s) included in the response,as well as information describing one or more characteristics of and/orassociated with the response, if desired) is stored as part of theservice model, as indicated at 315.

While operations 300 and 310 are shown as taking place serially, theseoperations may be performed in parallel or in the opposite order shownin other situations and/or embodiments. For example, a user caninitially enter information describing several user-specifiedtransactions (e.g., by selecting a production log file), before enablingthe service model generator to begin observing and recording actualtransactions taking place. Similarly, in some embodiments, a user canselect to enter information specifying a user-specified transactionwhile the service model generator is observing and recording actualtransactions. In other embodiments, a user may not be allowed to enteruser-specified transactions into the service model while transactionobservation and recording is taking place. In still other situations,operation 310 may be performed and operation 300 may not, or vice versa.

At 320, a determination as to whether the model building process iscomplete is made. This determination can involve detecting whether theservice model generator has stopped observing and recording actualtransactions and/or whether a user has finished entering informationdescribing user-specified transactions (e.g., as determined by the userselecting a “finish” option or other appropriate option from a userinterface). Such a determination can also be made using other stimuli.For example, in one embodiment, this determination can be based uponwhether a user has selected to save a service model (e.g., when the usersaves a service model, that service model is assumed to be complete).

If the model building process has finished, the service model generatorcan perform additional processing. For example, the service modelgenerator can store information identifying an unknown transaction of aknown type, as shown in 330. This information includes informationidentifying a known type of request that includes one or more unknownattributes, as well as an associated response. Similarly, the servicemodel generator can store information identifying an unknown transactionof an unknown type, as shown at 340. The information identifying theunknown transaction of unknown type can include information identifyingan unknown command, information identifying unknown attributes, as wellas information identifying default characteristics and a defaultresponse.

In addition to adding information describing unknown transactions ofknown and unknown types, other processing can also take place after thebasic model building process completes. For example, in someembodiments, the service model supports time sensitive responses. Inthese embodiments, the service model generator processes the responseinformation in the model in order to substitute time sensitiveattributes for actual observed attributes, as shown at 350. Thus, anactual attribute “10:59 PM Oct. 1, 2009” can be replaced with a timesensitive value such as “[SYSTEM CLOCK+11 HOURS]”. When the model isused to generate responses for the virtualized service, the timesensitive value is used to calculate the appropriate attribute toinclude in each response. Thus, if the model is being used to virtualizea service and the response attribute includes the time sensitive value[SYSTEM CLOCK+11 HOURS], the response generated based upon the modelwill include the value generated by adding 11 hours to the system clockvalue at the time the request was received. In general, time sensitivevalues specify an observable time, such as a time value included in arequest or the current system clock time, and a delta, such as an amountof time to add or subtract from the specified observable time. Timesensitive values can be included in the response information for alltypes (known and unknown) of transactions.

To generate the appropriate time sensitive response values, the servicemodel generator can (as part of observation and recording of actualtransactions) record information in the service model indicating thecurrent system clock value (e.g., a time and/or date) at each time thata response is received by the service being modeled. Thus, for a giventransaction, the characteristics for that transaction can include thesystem clock value (at the service being modeled) at the time that therequest was received by the service being modeled.

After the model building process completes, the service model generatoridentifies which responses in the model, if any, should be modified toinclude time sensitive values. If there is no time value in the observedresponse, there is no need to modify the information describing theobserved response to include a time sensitive value.

If instead there is a time value included in the observed response, theservice model generator can then determine whether the correspondingrequest includes a time value as one of its attributes. If thecorresponding request does include a time value, the service modelgenerator can calculate the difference between the time value in therequest and the time value in the response. This difference is then usedto generate the time sensitive value, and the time value in the responseis replaced with the time sensitive value. Thus, if the request includesthe time value “Sep. 1, 2000” and the response includes the time value“Sep. 14, 2000”, the response's time value can be replaced with thetime-sensitive value “[REQUEST DATE+13 DAYS]”.

If the corresponding request does not include a time value, the servicemodel generator compares the time value in the response to the recordedsystem clock time in the transaction's characteristics. This differenceis then used to generate the time sensitive value, and the time value inthe response is replaced with the time sensitive value. For example, ifthe response includes the value 6:01 AM and the characteristics indicatethat the service received the corresponding request at a system clocktime of 5:59 AM, the time sensitive value is “[SYSTEM CLOCK+2 MINUTES]”.

If there are multiple time values in the same response, the aboveprocedure can be repeated for each different time value. Thus, if thereare three time values in a response, three different time sensitivevalues can be calculated, and the existing time values can each bereplaced by a corresponding time sensitive value.

In some embodiments, a user can modify an observed response to include atime sensitive value (e.g., by selecting to add a time sensitive valuevia a pull-down menu) or add a user-specified response that includes atime sensitive value. In such embodiments, the user can specify whetherthe time sensitive value depends upon a time value in the request or thesystem clock value as well as how the observable time (i.e., the systemclock value or time value in the request) should be modified (e.g., byspecifying an amount of time to be added to the observable time).

Another type of post-model building processing that the service modelgenerator can perform involves replacing attribute values (e.g.,strings) in the response information associated with unknowntransactions of known type with request sensitive values, as shown at360. The request sensitive values link an attribute included in therequest to a value included in the response. For example, theinformation describing an unknown transaction of known type can specifythat there are three attributes included in requests of that knowntransaction type. The response information for that unknown transactioncan be modified to include a request sensitive value that indicates thatthe value of the third attribute of the request should be used as thevalue of the first attribute of the response, instead of an actualobserved or user-specified value.

When the model is used, the response generated by the virtualizedservice will include the value indicated by the request sensitive value.For example, the model can include three known transactions of a giventransaction type, as well as one unknown transaction of that type. Theinformation describing the unknown transaction can indicate that thesingle response attribute is a request sensitive attribute that shouldbe the same as the first attribute of the request. A request of thattype that contains an unknown first attribute (i.e., an attribute thatdoes not match the attribute(s) stored for the three known transactionsof that type in the model) can be sent to the virtualized service. Inresponse to receiving this request and accessing the request sensitivevalue specified in the response information for the unknown transaction,the virtualized service returns a response that includes the value ofthe first attribute that was contained in the received response.

To generate request sensitive values, the service model generatorcompares each request attribute in each known transaction with theresponse attribute(s) for the same transaction. If a match or otherdependency is found, the service model generator can create a requestsensitive value that identifies an attribute in the request and adependency (if the dependency is one other than identity). For example,if the information describing a known transaction of type A indicatesthat the request includes the string “UserID” as the first requestattribute and that the corresponding response includes the string“UserID” as its second response attribute, a request sensitive valuespecifying “[REQUEST ATT 1]” (first request attribute) can be generated.The service model generator then replaces the second response attributefor the unknown transaction of transaction type A with the requestsensitive value.

In some embodiments, all known transactions of a given type areprocessed before the corresponding unknown transaction's responseinformation is modified. The request sensitive value is used to replaceone of the unknown transaction's response attributes only if all of theknown transactions of that type exhibit the same dependency. In otherembodiments, less stringent requirements are imposed (e.g., areplacement may be made if some but not all of the known transactionsexhibit the same dependency).

A service model generator can perform other types of processing inaddition to those described above. For example, service model generatorcan process information stored as part of the characteristics of eachtransaction in order to identify availability windows for the service,load patterns for the service, and the like. If patterns are identified,the service model generator can update the service model to includeinformation identifying such patterns. For example, if an access windowis identified for a particular type of transaction, the service modelgenerator can modify the unknown transaction of that type to include acharacteristic indicating that a response (or a particular type ofresponse) will only be generated if the request is received during theidentified access window.

Additionally, if the service model generator is recording statefultransactions, the processing performed after transactions are recordedcan involve identifying and merging transactions into conversations, asis described in more detail below with respect to FIG. 6.

It is noted that a user can restart the model building process for aparticular model subsequent to performance of processing operations likeoperations 330-360 (e.g., by restarting the observation and recordingoperations or by selecting to edit an existing model). In suchsituations, the processing operations, such as processing operations330-360, may be repeated, if needed, after the restarted model buildingprocess completes (e.g., if a transaction of a new type is added to themodel, a corresponding unknown transaction of that type can be added tothe model by repeating operation 330).

FIG. 4 is a block diagram of a system that presents a virtual databaseservice. While a virtual database service is described in this example,it is noted that other types of services can be virtualized in a similarmanner.

As shown, the system of FIG. 4 includes an application under test 410, adevice manager 450, a testing driver 425, a database driver 435, adatabase 430, a testing module 460, virtual database service 470,service model generator 20, user interface 480, and database model 440.These components can be implemented on the same computing device in someembodiments. However, in many embodiments, various components can beimplemented on different computing devices. For example, applicationunder test 410, device manager 450, and testing driver 425 can beimplemented on one computing device, while database driver 435 isimplemented on another, and testing module 460 is implemented on yetanother. Thus, the various components can be configured to communicatevia a network.

In this example, testing module 460 includes both a service modelgenerator 20 to generate database model 440 of database 430 and avirtual database service 470 that uses database model 440 to virtualizedatabase 430. User interface 480 can be used to configure and controlthe model building process performed by service model generator 20, asdescribed above, as well as to deploy the virtual database service 470.

In order to deploy virtual database service 470, a user selects database430 for virtualization and causes database model 440 to be generated.The user then selects to deploy the virtual database service. Deploymentinvolves starting a request processing module that is configured to usethe appropriate service model to process requests. The requestprocessing module can be deployed within a software container (e.g., aJava 2 Platform, Enterprise Edition (J2EE or JavaEE) container) devotedto providing virtual service environments. If desired, several instancesof the request processing module, each of which uses the same servicemodel, can be deployed at the same time. The executing requestprocessing module accesses database model 440 in order to presentvirtual database service 470.

A related testing driver 425 or other testing module can also bedeployed (e.g., if application under test 410 is not executing in thesame container as the request processing module) on the client system(i.e., the system that includes the application under test) as part ofthe deployment process. This testing driver can be configured to providerequests generated by the application under test 410 to virtual databaseservice 470, as well as to provide responses generated by virtualdatabase service 470 to the application under test. A similar driver (oreven the same testing driver) can also operate as part of service modelgenerator 20 during the model building process described above.

In the illustrated embodiment, testing driver 425 causes databaserequests generated by application under test 410 to be provided tovirtual database service 470 instead of database 430. Testing driver 425first communicates with the driver manager 450 on the same system asapplication under test 410. Testing driver 425 has the driver manager450 update the driver management information for that system to indicatethat requests being sent to database driver 435 should actually be sentto testing driver 425. Testing driver 425 can then provide thoserequests to virtual database service 470.

As requests are received from application under test 410, virtualdatabase service 470 can use database model 440 to select responses toreturn to application 410. FIG. 5 provides an example of how a servicemodel such as database model 440 can be used to select responses.

During the deployment process (or during ongoing use of the virtualdatabase service), the user can interact with testing module 460 viauser interface 480 in order to control how virtual database service 470operates. For example, in one embodiment, the database service model 440includes characteristic information for each transaction that controlshow quickly responses are sent after requests are received. The user canuse a slider bar or other input mechanism within user interface 480 tospecify at what percentage speed the virtual database service 470 shouldoperate, relative to the observed speed of database 430. For example, auser can select to have virtual database service 470 operate at 110% ofobserved speed in order to identify the effect of speeding up database430 on application under test 410.

FIG. 5 is a flowchart of a method of presenting a virtual service. Thismethod can be performed by a testing or training system in which avirtual service has been implemented. The virtual service includes arequest processing module (e.g., as implemented as a process executingin a container) and a service model (e.g., such as service model 40 ofFIG. 1) representing the service being virtualized. Several requestprocessing modules can be deployed at the same time, and thus thevarious operations of FIG. 5 can be performed by different requestprocessing modules operating at substantially the same time tovirtualize the same service.

At 500, the request processing module waits for a request. If a requestis detected, the request processing module then determines whether thevirtual service is operating in pass-through mode, as shown at 505. Inpass-through mode, the virtual service is not actually responding torequests. Instead, the virtual service is simply receiving requests andthen forwarding those requests to the actual service being virtualized.In some embodiments, while the virtual service operates in pass-throughmode, a service model generator can observe and record such requests byadding information describing those requests (and their correspondingresponses) to the existing model of the service. A user can selectwhether to operate a virtual service is pass-through mode by selectingan option in a user interface. In some embodiments, the user candynamically change the mode (pass-through or non-pass-through) in whichthe virtual service is operating while operation of the virtual serviceis ongoing (e.g., without having to stop and restart or undeploy andredeploy the virtual service).

If the virtual service is currently operating in pass-through mode, therequest detected at 500 is provided to the actual service beingvirtualized, as shown at 540. A response can then be received from theactual service, as shown at 545. The received response can then beprovided to the requester, as indicated at 550. In many embodiments, thesame mechanisms used to send and receive requests and responses whilegenerating a service model are also used to operate the virtual servicein pass-through mode.

If the virtual service is not operating in pass-through mode, therequest processing module determines whether the request is part of atransaction of a known type. In this example, this determination is madeby determining whether the request contains a known command, as shown at510. A known command is a command that was included in an actualobserved or user specified transaction that is part of the service modelfor the service being virtualized. If the request does not contain aknown command or is otherwise not part of a transaction of a known type(e.g., if the request does not contain the appropriate attributes), aresponse associated with an unknown transaction of unknown type isselected, as indicated at 510 and 515.

If instead the request is part of a transaction of a known type, adetermination is made as to whether the request is part of a knowntransaction. This determination can involve detecting whether any of theattributes included in the request are unknown attributes (i.e.,attributes having values that were not included in the actual observedand/or user-specified requests included in the service model), as shownat 520. If the request includes one or more unknown attributes, therequest processing module selects a default response associated with theappropriate unknown transaction of known type in the model, as shown at530. Otherwise, the request processing module selects the appropriateactual observed or user-specified response from a known transaction ofknown type from the model.

In some embodiments, determination of whether the attributes of the newrequest match the known attributes identified in the model is performedusing an exact matching process. For example, regular expressions can beused to match a received request to the requests identified in theservice model. Alternatively, less precise matching can be performed.For example, “starts with” or “contains” type matching can be performedas part of operation 520. These types of matching can thus identify thatthe new request matches an actual, known transaction, even if the newrequest's attributes differ somewhat from those in the actual, knowntransaction.

The request processing module can optionally manipulate the selectedresponse in a manner indicated by the model, as shown at 535. Forexample, if the selected request includes a time sensitive value, therequest processing module can use that time sensitive value to calculatean actual time value. The request processing module can then replace thetime sensitive value in the response with the calculated time value.Similarly, if the selected response includes a request sensitive value,the request processing module can calculate the appropriate responseattribute, as indicated by the request sensitive value, and then replacethe request sensitive value with the calculated response attribute.Likewise, if the selected response is associated with a characteristicspecifying an access window, and if the request was received outside ofthe specified access window, additional manipulation (e.g., to replacethe stored response with an appropriate error message) can be performed.Many other types of manipulation can also be performed in response toinformation contained in the service model. Once the response has beenmanipulated, if needed, the final response can be returned to therequester, as shown at 550.

FIG. 6 is an illustration of a data model that can be used to storeinformation representing both stateful and stateless transactions.Service model information such as that shown in FIG. 2 can be stored insuch a data model. As shown, the data model includes five data patterns:traffic pattern 610, conversation pattern 620, transaction pattern 630,request pattern 640, and response pattern 650.

Traffic pattern 610 can be used to store information identifying aparticular service and the transactions that have been observed orotherwise added to the model of the identified service. Each servicemodel can include a single instance of traffic pattern 610. As shown,traffic pattern 610 includes created field 611, which stores dateinformation identifying when the service model of that particularservice was initially created. Traffic pattern 610 also includeslastModified field 612, which stores date information identifying themost recent time at which any of the information in the service model ofthe particular service was modified.

Traffic pattern 610 also includes an unknownResponse field 613.UnknownResponse field 613 stores information identifying the particularinstance of the response pattern that stores information identifying theresponse to use for unknown transactions of unknown types. Accordingly,in embodiments employing the data pattern of FIG. 6, if an unknowntransaction of unknown type is detected by a request processing module,the request processing module will use the response pattern instanceidentified in unknownResponse field 613 to generate a response.

Traffic pattern 610 includes conversations field 614. Conversationsfield 614 can identify one or more instances of conversation pattern620. Conversation pattern 620 stores information representing a set oftwo or more stateful transactions. Such a set of stateful transactionsis referred to herein as a conversation. The instance(s) of conversationpattern 620 identified in conversations field 614 identify all of theobserved and/or user-specified conversations for the service beingmodeled. If the particular service being modeled does not include anystateful transactions (e.g., if a user has specified that the serviceonly performs stateless transactions, or if no stateful transactionshave been observed or specified by a user), conversations field 614 willnot identify any instances of conversation pattern 620.

Traffic pattern 610 additionally includes statelessConversation field615. This field can identify one or more instances of transactionpattern 630. Transaction pattern 630 stores information representing atransaction. Each instance of transaction pattern 630 identified instatelessConversation field 615 stores information identifying astateless transaction that was either observed or specified by a user.StatelessConversation field 615 can identify instances of transactionpattern 630 associated with both known and unknown transactions of knowntypes. If the particular service being modeled does not include anystateless transactions, statelessConversation field 615 will notidentify any instances of transaction pattern 630.

Type field 616 can store one of two values: INSTANCE or TOKEN thatidentifies the type of stateful transactions, if any, provided by theservice being modeled. Instance statefulness occurs when thecommunication protocol used by the service is itself stateful. Wheninstance statefulness is used, each interaction between the service anda particular requester is handled by a separate instance of the serviceexecuting in its own memory space, such that interactions involvingdifferent requesters are handled by different instances of the serviceexecuting in different, independent memory space. Token statefulnessoccurs when the communication protocol used by the service is not itselfstateful. When token statefulness is implemented, a single instance ofthe service interacts with all requesters. In token statefulnessscenarios, each request and response can include tokens (e.g., such as“cookies” used in HTTP) that identify the particular requester that sentthe request or should receive the response. In some embodiments, thevalue of this field is set automatically (e.g., by a service modelgenerator) when a user selects the communication protocol(s) used tocommunicate with the service to be modeled.

As noted above, conversation pattern 620 stores information identifyinga set of stateful transactions. A given service model can include ninstances of conversation pattern 620, where n is an integer that isgreater than or equal to zero.

Conversation pattern 620 includes a starter field 621. This field storesinformation identifying an instance of transaction pattern 630associated with a starter transaction. The starter transaction is atransaction that acts as the first transaction in a stateful series oftransactions (e.g., a login transaction). In at least some embodiments,all starter transactions are unknown transactions of known type, as willbe described in more detail below. The particular transaction type touse as a starter transaction can be specified by a user during theservice model configuration process.

Conversation pattern 620 also includes reset field 622. Reset field 622stores information identifying one or more instances of transactionpattern 630, each of which is associated with a reset transaction (sucha reset transaction can be a known or unknown transaction). The value ofreset field 622 can be provided by a user (e.g., the user can beprompted to identify the reset transaction(s) for each conversation). Areset transaction is a transaction that, if detected, causes the flow ofthe conversation to return to the point just after performance of thestarter transaction. For example, if a conversation includes foursequential transactions (where the starter transaction is the first ofthe four sequential transactions), and the reset transaction is detectedjust after performance of the third transaction in the conversation, thestate of the conversation will return to the state that exists justafter performance of the first transaction.

Conversation pattern 620 also includes a goodbye field 623. This fieldstores information identifying an instance of transaction pattern 630associated with one or more goodbye transactions (of known or unknowntype) for the conversation. A goodbye transaction is a transaction thatcauses the conversation to end. To reenter the conversation after agoodbye transaction is performed, the starter transaction for thatconversation would need to be reperformed.

Transaction pattern 630 stores information identifying a transaction.Transaction pattern 630 includes request field 631, responses field 632,parent field 633, children field 634, and matchTolerance field 635.Transaction pattern 630 can be used to store stateful and statelesstransactions (in some instances, the same transaction can occur bothwithin a conversation and in a stateless situation where no conversationis currently ongoing). Transactions that are always stateless will notinclude values of parent field 633, children field 634, ormatchTolerance field 635.

Request field 631 identifies the instance of request pattern 640 thatstores information identifying the request (e.g., by command andattributes) portion of the transaction. Similarly, responses field 632identifies one or more instances of response pattern 650 that storeinformation identifying the response(s) that are part of thattransaction. Each instance of response pattern 650 stores one responseattribute (e.g., like those shown in FIG. 2), and thus if responsesfield 632 identifies multiple response patterns, it indicates that eachof the identified response patterns should be used to generate aresponse when the corresponding request is received.

Parent field 633 stores a value identifying the instance of transactionpattern 630 associated with the transaction that occurs immediatelybefore the current transaction in a conversation. Thus, if transactionpattern 630 stores information identifying the second transaction in aconversation (where the starter transaction is the first transaction inthe conversation), parent field 633 can identify the instance oftransaction pattern 630 associated with the starter transaction.

Similarly, children field 634 can store information identifying eachinstance of transaction pattern 630 associated with a child transactionof the current transaction. Thus, if transaction pattern 630 storesinformation identifying the second transaction in a conversation,children field 634 can store information identifying the instance oftransaction pattern 630 that stores the third transaction in theconversation. It is noted that children field 634 can identify more thanone transaction.

In some embodiments, parent field 633 and children field 634 onlyidentify unknown transactions of known type. In such embodiments, knowntransactions are identified as properties of corresponding unknowntransactions of the same type that occur at the same point in aconversation.

MatchTolerance field 635 stores one of three values: STRICT, CLOSE, orLOOSE. The stored value indicates the match tolerance for a requestreceived immediately subsequent to the current transaction. Stricttolerance indicates that, if a conversation is ongoing, the requestreceived immediately after the current transaction is only allowed tomatch transactions identified in the current transaction's childrenfield 634. If a received request does not match one of the childrentransactions and is not a goodbye or reset transaction, the receivedrequest will be handled as an unknown transaction of unknown type, evenif the service model does contain a matching transaction elsewhere.

If instead close tolerance is specified, the request receivedimmediately after the current transaction can match any of the currenttransaction's children, as well as any of the current transaction'ssibling transactions. Sibling transactions are all transactions that areidentified in the children field of the transaction identified by thecurrent transactions parent field. If the next request does not matchany of these children or sibling transactions and is not a goodbye orreset transaction for the conversation, the next request will be handledas an unknown transaction of unknown type.

If loose tolerance is specified, even more transactions are candidatesfor matching the next received request. In one embodiment, loosetolerance indicates that the next request can match any of the currenttransaction's children transactions, sibling transactions, or parenttransactions and parents' sibling transactions. In another embodiment,loose tolerance indicates that the next request can match any of thetransactions included in the conversation, other than the startertransaction. If the next request does not match any of the transactionsallowed by the loose tolerance and is not a goodbye or reset transactionfor the conversation, the next request will be handled as an unknowntransaction of unknown type.

Thus, the matchTolerance field 635 effectively identifies a subset ofthe transactions within the service model that are candidates formatching the next request received after the current transaction. Thevalue of the matchTolerance field 635 can be set by a service modelgenerator (e.g., based upon user input, a default configurationassociated with the communication protocol used to communicate with theservice being modeled, or the like). Different transactions within thesame service model, as well as different transactions within the sameconversation, can have different levels of match tolerance.

In some embodiments, only unknown transactions of known type have valuesin matchTolerance field 635, parent field 633 and/or children field 634.In such embodiments, one or more known transactions of known type can beidentified as properties (not shown) of a corresponding unknowntransaction of the same known type. In such a situation, the parent,child, and/or match tolerance of the corresponding unknown transactionwill be used when processing a request received subsequent to one of theknown transactions of known type.

Request pattern 640 includes a command field 641, attributes field 642,and characteristics field 643. Each instance of request pattern 640stores information identifying a particular request. A service modelgenerator can allocate an instance of request pattern 640 for eachobserved transaction, user-specified transaction, and unknowntransaction of known type.

Command field 641 stores a string that identifies the command containedin the request. Attributes field 641 stores a parameter list thatincludes zero or more parameters, each of which represents an attributeof the request. The parameter list can include observed, user-specified,and unknown attributes, as discussed above with respect to FIG. 2.

Characteristics field 643 stores a parameter list identifying zero ormore characteristics associated with the request. Each parameter in thelist can identify a different characteristic. Examples ofcharacteristics can include the time at which the request was sent, thesystem clock time at which the request was received by the service beingmodeled, network and/or system conditions that were present when therequest was received, and the like. The parameters stored incharacteristics field 643 can be used to generate time sensitive values,as well as to model actual conditions such as response timing andavailability windows.

Response pattern 650 includes an attribute field 651 and acharacteristics field 652. Attribute field 651 stores a string thatrepresents a response attribute. As noted above, a given transaction canhave multiple response attributes (e.g., responses field 632 oftransaction pattern 630 can identify multiple instances of responsepattern 650), and thus generating a response can involve accessingmultiple response patterns in order to include the string identified ineach of the response patterns' attribute field 651 in the response.Attribute field 651 can store a user-specified or observer responseattribute, as well as values, like request sensitive values and timesensitive values, generated by the service model generator.

Characteristics field 652 stores a parameter list containing zero ormore parameters. Each parameter identifies a characteristic of theresponse, such as the system clock time when the response was sent tothe requester by the service, network and/or system conditions that werepresent when the response was sent, and the like.

Whenever a service model generator is observing and recording statefultransactions that are part of a conversation, the service modelgenerator can first act to store information identifying each observedtransaction (e.g., by storing information identifying each transactionin a transaction pattern 630, response pattern 640, and one or moreresponse patterns 650. The service model generator can also storeinformation identifying the order in which the recorded transactionswere observed.

After the observation and recording process is complete, the servicemodel can begin generating information identifying one or moreconversations and updating the conversation-related fields of one ormore transaction patterns. If the service supports token statefulness,the service model generator can then prompt the user to specify thestarter transaction(s). For example, the service model generator canprovide a list of all observed transactions to the user, and prompt theuser to select which, if any, of those observed transactions are startertransactions.

The service model generator can identify all transactions that were partof the same conversation. When instance statefulness is implemented, aconversation will include all observed transactions for a given instanceof the service; when token statefulness is implemented, a conversationwill include all observed transactions that include the same token(e.g., as a request and/or response attribute), where each conversationbegins with one of the user-specified starter transactions. Oncetransactions that are part of the same conversation have beenidentified, the service model generator can used the informationidentifying the order in which transactions were observed to place thosetransactions in temporal order.

The service model generator can then attempt to merge one or moreconversations into a single conversation. For example, the service modelgenerator can determine whether more than one of the conversationsincludes the same starter transaction. If so, the service modelgenerator can merge those conversations into a single conversation thatbegins with the same starter transaction. If the starter transactions ofmultiple different conversations are not identical but are structurallysimilar transactions of the same type (e.g., if two conversations beginwith start transactions that include the same command and the samenumber and type of attributes, but the actual attribute values differ),those conversations can also be merged into a single conversation.

For each conversation identified in this merging process (this includesconversations created by merging multiple other conversations, as wellas independent conversations that cannot be merged with others), theservice model generator can allocate an instance of conversation pattern620 to store information identifying that conversation. As noted above,the starter transaction for each conversation is an unknown transactionof known type. Accordingly, if the service model does not alreadyinclude an unknown transaction of that type, the service model generatorcan allocate an instance of transaction pattern 630 to store thatunknown transaction. Once the unknown transaction acting as the startertransaction is included within the model, the starter field 621 of theconversation pattern 630 is updated to identify that unknowntransaction.

If any known transactions of that type were observed (e.g., such asthose that were merged in the above example) as the first transaction inthe conversation, those transactions can then be added to theconversation as properties of the unknown transaction of that type.Adding these transactions to the conversation involves updating aproperties field (not shown) of the unknown starter transaction toidentify each of the known transactions of that type that were observedas starter transactions of the merged conversation.

This merging process can be repeated at each level of the conversation.For example, if four conversations, each of which includes at leastthree sequential transactions, are merged, the merging process cancontinue for each of the next two transactions within each conversation.Thus, after the known starter transactions are added as properties ofthe unknown starter transaction, the service model generator can observethe next transactions to occur within the merged conversation, anddetermine whether any of the next transactions can also be merged. Theservice model generator can also insert unknown transactions for eachtype of known transaction encountered in the conversation, and then addthe known transactions as properties of those unknown transactions. Evenif no merging is performed, an unknown transaction of known type will beincluded for each known transaction observed in a conversation. Parentand children fields are updated to indicate the flow of theconversation.

For example, assume three conversations have been observed, as shown inFIG. 7A. These conversations all include commands that can be used witha computer reservation system used to reserve flights with one or moreairlines. The first conversation includes transactions 1.1-1.4.Transaction 1.1 includes a request to “getFlightInfo” specifying anorigination city CityA and a destination city CityB. The response (notshown) to this request includes a list of flights, if any, scheduledbetween CityA and CityB. Transaction 1.2 includes a request for thecapacity of one of the flights provided in response to the“getFlightInfo” request, and a response (not shown) indicating whetherthat flight has any available capacity. Transaction 1.3 includes arequest to reserve that flight, and a response (not shown) indicatingwhether or not the flight reservation was successful. Transaction 1.4includes a request to hold a specific seat on the flight, and a response(not shown) indicating whether the request was successful.

The second conversation includes transactions 2.1-2.2. Transaction 2.1includes a request to “getFlightInfo” specifying an origination cityCityC and a destination city CityD. The response (not shown) to thisrequest includes a list of flights, if any, scheduled between CityC andCityD. Transaction 2.2 includes a request to reserve one of thoseflights, and a response (not shown) indicating whether or not the flightreservation was successful.

The third conversation includes transactions 3.1-3.4. Transaction 3.1includes a request to “getFlightInfo” specifying an origination cityCityA and a destination city CityD. The response (not shown) to thisrequest includes a list of flights, if any, scheduled between CityA andCityD. Transaction 3.2 includes a request for the capacity of one of theflights provided in response to the “getFlightInfo” request, and aresponse (not shown) indicating whether that flight has any availablecapacity. Transaction 3.3 includes a request to hold a seat on thatflight, and a response (not shown) indicating whether or not the requestwas successful. Transaction 3.4 includes a request to reserve theflight, and a response (not shown) indicating whether the flightreservation was successful.

The service model generator then processes the observed transactions inorder to build a tree representing the conversations, as shown in FIG.7B. Initially, the service model generator identifies that the threeconversations can be merged because all three start with the same typeof known transaction: getFlightInfo, despite the fact that the observedattributes differ among each of the three starter transactions. Inresponse to this identification, the service model generator identifiesthe unknown transaction of that type, getFlightInfo, as the startertransaction for the merged conversation and adds this unknowntransaction to the service model (while a stateless unknowngetFlightInfo transaction or other stateful unknown getFlightInfotransactions may already exist in the service model, none of these othertransactions occur at the same point in the stateful conversation asthis one, so a new unknown transaction will always be added). Theservice model generator then updates the unknown getFlightInfotransaction's properties to identify the known transactions 1.1, 2.1,and 3.1 that were observed at the same point in the conversation. Theseproperties are shown in brackets in FIG. 7B.

The service model generator then examines the second transaction in eachconversation to see if any of those transactions can be merged. Here,the first and third conversation each include a structurally similarsecond transaction of type “capacity.” Accordingly, these twoconversations can again be merged at the second transaction level. To doso, the service model generator creates a new instance of an unknowntransaction of type capacity. The children field of the unknowngetFlightInfo transaction is updated to identify the new unknowncapacity transaction, and the parent field of the new unknown capacitytransaction is updated to identify the unknown getFlightInfotransaction. The two known transactions 1.2 and 3.2 that were observedat this point in the first and third conversations are then added asproperties of the unknown capacity transaction.

The second transaction in the second conversation, which is of type“reserveFlight,” cannot be merged with the second transaction of theother two conversations, however. Accordingly, the service modelgenerator will create a new unknown transaction of this type and updatethe children field of the unknown getFlightInfo to identify this newunknown reserveFlight transaction. Similarly, the parent field of thenew unknown reserveFlight transaction is updated to identify the unknowngetFlightInfo transaction. The single known transaction of this type(transaction 2.2) is then added as a property of the new unknownreserveFlight transaction.

Thus, after processing the second transaction in each of the threeconversations, the service model will indicate that the unknowngetFlightInfo starter transaction has two children, an unknown capacitytransaction and an unknown reserveFlight transaction.

The service model generator then processes the third transaction in eachconversation. As shown in FIG. 7A, only the first and thirdconversations include more than two transactions, and each conversationincludes a different transaction at this point in the conversation.Accordingly, it is not possible to merge the transactions at this pointin the conversation. As such, the service model generator creates a newunknown reserveFlight transaction to correspond to transaction 1.3, anda new unknown seat transaction to correspond to transaction 3.3. Thechildren field of the new unknown capacity transaction is updated toidentify both of these unknown transactions as children, and the parentfield of the new unknown reserveFlight and seat transactions are updatedto identify the unknown capacity transaction. The observed knowntransactions are added as properties of their corresponding unknowntransactions, such that the unknown seat transaction identifiestransaction 3.3 as one of its properties and the unknown reserveFlighttransaction identifies transaction 1.3 as one of its properties.

It is noted that there are now two unknown reserveFlight transactions inthe same conversation. Despite being unknown transactions of the sametype, these two transactions have different values of their parent andchildren fields and properties. These differences reflect the fact thatthese transactions occur at different points within the conversation.

The service model generator then processes the final transactions 1.4and 3.4 in the first and third conversations in the same manner as theprevious transactions. Since the transactions that preceded thesetransactions could not be merged, these transactions also cannot bemerged (furthermore, in this example these transactions can also not bemerged since they are of different types. Accordingly, the service modelgenerator adds a new unknown transaction for each of transactions 1.4and 3.4. The new unknown reserveFlight transaction corresponding totransaction 3.4 lists transaction 3.4 as one of its properties, and thenew unknown seat transaction corresponding to transaction 1.4 liststransaction 1.4 as one of its properties. The parent field of the newunknown reserveFlight transaction is updated to identify the precedingunknown seat transaction (“seat [3.3]” in FIG. 7B) and the parent fieldof the new unknown seat transaction is updated to identify the precedingunknown reserveFlight transaction (“reserveFlight [1.3] in FIG. 7B).Similarly, the children fields of the preceding unknown transactions areupdated, such that the children field of the preceding unknown seattransaction (“seat [3.3]”) identifies the new unknown reserveFlighttransaction (“reserveFlight [3.4]”) and the children field of thepreceding unknown reserveFlight transaction (“reserveFlight [1.3]”)identifies the new unknown seat transaction (“seat [1.4]”).

To use a service model that is implemented using the data pattern ofFIG. 6, a request processing module can process each received request inthe following manner. If no conversations are currently taking place,the request processing module can first determine whether a receivedrequest is part of any starter transaction by comparing the receivedrequest to the requests included in the starter transactions identifiedin each instance of conversation pattern 620 identified in conversationsfield 614. If so, the request processing module can select theappropriate instance of conversation pattern 620 (i.e., the instancewhose starter field 621 identifies the transaction that matches thereceived request) in order to process subsequently received requests.The request processing module can also identify the appropriate instanceof transaction pattern 630 associated with the transaction matching thereceived request in order to generate an appropriate response to be sentto the requester. Identifying the appropriate instance can involveexamining each known transaction identified as a property of the startertransaction, in order to see if the new request matches a knowntransaction. If the new request matches a known transaction, that knowntransaction is used to respond. Otherwise, the unknown transaction isused to respond.

If the received request is not part of a starter transaction and noconversation is currently taking place, the request processing modulecan identify whether the request is part of one of the transactionsidentified in statelessConversation field 615. If a match is found, therequest processing module can use the information associated with thematching transaction to generate a response to be sent to the requester.If no match is found, the request processing module can access theinstance of response pattern 650 identified in unknownResponse field 613and use the information stored within that response pattern instance togenerate a response.

If a conversation is already taking place, the request processing modulecan determine whether the received request is a goodbye or resettransaction for the conversation (as identified by goodbye field 623 orreset field 622 of the instance of conversation pattern 620 associatedwith the ongoing conversation). If so, the information describing thematching goodbye or reset transaction can be used to generate aresponse, and the request processing module can update its stateaccordingly (e.g., to indicate that no conversation is currently ongoingif the request matched the goodbye transaction, or the move the state ofthe conversation back to the point after handling the startertransaction if the request matched the reset transaction).

If the received request is not a goodbye or reset transaction for theongoing conversation, the request processing module can determinewhether the request matches any of the transactions that are allowed tooccur at that particular point in the conversation (e.g., as specifiedby the matchTolerance field 635 of the last transaction handled in theconversation). If so, the request processing module can use the matchingtransaction to generate a response. If a matching unknown transaction isfound, the request processing module can first determine whether thereceived request matches any of the known transactions that areproperties of the matching unknown transaction. If so, the requestprocessing module can use the known transaction to generate a response.Otherwise, the request processing module can use the matching unknowntransaction to generate the response.

If a conversation is already taking place, the received request is not agoodbye or reset transaction for the conversation, and the receivedrequest does not match any of the transactions that are allowed to occurat that particular point in the conversation, the request processingmodule will generate the response identified in unknownResponse field613. This response will be generated even if the received request wouldhave matched one of the other transactions included in the servicemodel, since the request was received during a conversation. Receptionof such a request may also cause the existing state of the conversationto be discarded, such that the next request received from the requesterwill be handled as if there is no ongoing conversation.

FIG. 8 is a block diagram of software that can be stored on a testingclient. As shown, the testing client is a computing device 700 thatincludes a processor 702 (e.g., a microprocessor, programmable logicdevice (PLD), or application specific integrated circuit (ASIC)), one ormore interfaces 704, and memory 706. Instructions executable byprocessor 702 are stored in memory 706. These instructions areexecutable to implement application under test 410, device manager 450,and testing driver 425. Computing device 700 can be a personal computer,server, personal digital assistant, cell phone, laptop, workstation, orthe like. Memory 706 can each include various types of RAM (RandomAccess Memory), ROM (Read Only Memory), Flash memory, MEMS (MicroElectro-Mechanical Systems) memory, and the like. Processor 702, memory706, and interface(s) 704 are coupled to send and receive data andcontrol signals by a bus or other interconnect.

Interfaces 704 can each include an interface to a storage device onwhich instructions and/or data (e.g., such as data implementing aservice model) are stored. Interfaces 704 can also each include aninterface to a network, such as a local area network (LAN) or wide areanetwork (WAN) such as the Internet, for use in communicating otherdevices. Such an interface can allow application under test 410 to sendrequests to services via a network. Similarly, such an interface canallow testing driver 425 to communicate with a testing moduleimplemented on another computing device. Interface 704 can also includeinterfaces to various peripheral Input/Output (I/O) devices, such as amonitor, on which a graphical interface (e.g., allowing a user toconfigure and control the model building and/or model deploymentprocess) can be displayed.

FIG. 9 is a block diagram of software that can be stored on a testingserver. As shown, the testing server is implemented using computingdevice 800, which includes a processor 802 (e.g., a microprocessor,programmable logic device (PLD), or application specific integratedcircuit (ASIC)), one or more interfaces 804, and memory 806.Instructions executable by processor 802 are stored in memory 806. Theseinstructions are executable to implement testing module 460, whichincludes user interface 480 and service model generator 20, as well asvirtual service environment 850 which includes virtual service 880(1)and virtual service 880(2). The two virtual services can be differentinstances of the same virtual service or different virtual services.Each virtual service can be implemented as a request processing moduleexecuting in a container, where the request processing module isconfigured to use a specific service model to determine how to respondto requests.

Like computing device 700, computing device 800 can be a personalcomputer, server, personal digital assistant, cell phone, laptop,workstation, or the like. Memory 806 can each include various types ofRAM (Random Access Memory), ROM (Read Only Memory), Flash memory, MEMS(Micro Electro-Mechanical Systems) memory, and the like. Processor 802,memory 806, and interface(s) 804 are coupled to send and receive dataand control signals by a bus or other interconnect.

Interfaces 804 can each include an interface to a storage device onwhich instructions and/or data (e.g., such as data implementing aservice model) are stored. Interfaces 804 can also each include aninterface to a network, such as a local area network (LAN) or wide areanetwork (WAN) such as the Internet, for use in communicating otherdevices. Such an interface can allow virtual services 880(1) and 880(2)to receive requests and send responses via a network. Similarly, such aninterface can allow testing module 460 to communicate with anothercomputing device in order to, for example, deploy a testing driver.Interface 804 can also include interfaces to various peripheralInput/Output (I/O) devices, such as a monitor, on which a graphicalinterface (e.g., allowing a user to configure and control the modelbuilding and/or model deployment process) can be displayed.

In FIGS. 8 and 9, program instructions and data implementing varioussoftware components such as application under test 410, device manager450, testing driver 425, service model generator 20, user interface 480,testing module 460, virtual service 880(1), and virtual service 880(2)can be stored on various computer readable storage media such as memory706 and 806. In some embodiments, such program instructions can bestored on a computer readable storage medium such as a CD (CompactDisc), DVD (Digital Versatile Disc), hard disk, optical disk, tapedevice, floppy disk, and the like. In order to be executed by aprocessor, the instructions and data are loaded into memory from theother computer readable storage medium. The instructions and/or data canalso be transferred to a computing device for storage in memory via anetwork such as the Internet or upon a carrier medium. In oneembodiment, the components used implement a service model generator,testing module, testing driver, and the like are implemented using LISA(Live Interaction Service Architecture) (TM), available from iTKO, Inc.of Dallas, Tex.

It is noted that the above figures illustrate specific examples. Inother embodiments, different components can be used to implement thetesting functionality described above. For example, while specificsoftware components have been described as implementing specificfunctionality, this functionality can be implemented by differentcomponents than those depicted herein. For example, the functionality ofservice model generator 20 can be subdivided into multiple other testmanagement components or integrated into another component withintesting module 460. Furthermore, the specific components depicted in thefigures herein can be combined or subdivided into fewer or additionalcomponents.

Additionally, other components can be used instead of and/or in additionto those shown in the figures presented herein. Such other componentscan provide different or additional functionality instead of and/or inaddition to the functionality described herein. Furthermore, some of thefunctionality described herein can be eliminated in some embodiments.

Although the present invention has been described in connection withseveral embodiments, the invention is not intended to be limited to thespecific forms set forth herein. On the contrary, the present inventionis intended to cover such alternatives, modifications, and equivalentsas can be reasonably included within the scope of the invention asdefined by the appended claims.

What is claimed is:
 1. A method comprising: monitoring data trafficbetween a particular software component and a particular softwareservice; identifying a particular communication protocol utilized in thedata traffic; interpreting the data traffic, based on the identifiedparticular communication protocol, to identify a request of theparticular software service sent from the particular software componentand a response to the request sent from the particular softwarecomponent to the particular software component; and generating a virtualservice model of the particular software service from the identifiedrequest and identified response to the request.
 2. The method of claim1, further comprising parsing the identified request to identify acommand of the identified request, and the virtual service model isgenerated based on the identified command.
 3. The method of claim 2,wherein the identified request is further parsed to identify a requestattribute of the identified request, and the virtual service model isgenerated based on the identified request attribute.
 4. The method ofclaim 3, wherein the identified response is parsed to identify aresponse attribute of the identified response, wherein the responseattribute is at least partially dependent on the request attribute andthe virtual service model is generated based on the identified responseattribute.
 5. The method of claim 1, further comprising: grouping theidentified request with the identified response as a particulartransaction; and recording the particular transaction in the virtualservice model of the particular software service.
 6. The method of claim5, further comprising interpreting the data traffic, based on theidentified communication protocol, to identify transactioncharacteristics of the particular transaction, wherein the virtualservice model is generated based on the identified transactioncharacteristics of the particular transaction.
 7. The method of claim 6,wherein the transaction characteristics comprise timing information ofthe particular transaction and the virtual service model is generated tomodel responses to requests of the particular software service based onthe timing information.
 8. The method of claim 6, wherein thetransaction characteristics comprise one of information identifyingbandwidth usage during the particular transaction, informationidentifying processor usage during the particular transaction, andmemory usage during the particular transaction.
 9. The method of claim5, further comprising: identifying a second request of the particularsoftware service sent from the particular software component;identifying a response to the second request sent from the particularsoftware service to the particular software component; grouping thesecond request with the identified response to the second request as asecond transaction; and recording the second transaction in the virtualservice model of the particular software service.
 10. The method ofclaim 9, wherein the particular transaction is of a first transactiontype and the second transaction is of a second, different transactiontype.
 11. The method of claim 5, further comprising determining whetherthe transaction is a stateful transaction.
 12. The method of claim 1,wherein the virtual service model is configured to model operation ofthe particular software service within a virtual service environment.13. The method of claim 12, wherein the virtual service environment isat least one of a development, testing, load testing, integrationtesting, and training environment.
 14. The method of claim of claim 1,further comprising: monitoring second data traffic between theparticular software component and a second software service; identifyinga second communication protocol utilized in the second data traffic;interpreting the second data traffic, based on the second communicationprotocol, to identify a request of the second software service sent fromthe particular software component; interpreting the second data traffic,based on the second communication protocol, to identify a response tothe request sent from the second software service to the particularsoftware component; and generating a second virtual service model of thesecond software service from the identified request of the secondsoftware service and identified response to the request of the secondsoftware service, wherein the second software service is different fromthe particular software service.
 15. The method of claim 14, wherein thesecond communication protocol is different from the particularcommunication protocol.
 16. The method of claim 1, wherein theparticular software service is at least one of a web service, web site,legacy application, data service, order manager, transactional datastore, enterprise resource planning (ERP) system, and enterpriseapplication integration (EAI) system.
 17. The method of claim 1, furthercomprising: identifying that an attribute of the identified response isdependent on attributes of the identified request; and defining adependency of the attribute of the identified response on the values ofthe identified request in the virtual service model.
 18. The method ofclaim 1, wherein the request comprises one of a method call to anobject, a SOAP message, a Java messaging service (JMS) message, arequest to access a web page, a request to access a web service, adatabase query, and packets destined for a particular network socket,and the like.
 19. A computer program product comprising a computerreadable storage medium comprising computer readable program codeembodied therewith, the computer readable program code comprising:computer readable program code configured to monitor data trafficbetween a particular software component and a particular softwareservice; computer readable program code configured to identify aparticular communication protocol utilized in the data traffic; computerreadable program code configured to interpret the data traffic, based onthe identified particular communication protocol, to identify a requestof the particular software service sent from the particular softwarecomponent and a response to the request sent from the particularsoftware service to the particular software component; and computerreadable program code configured to generate a virtual service model ofthe particular software service from the identified request andidentified response to the request.
 20. A system comprising: a processordevice; a memory element; and a service model generator adapted to:monitor data traffic between a particular software component and aparticular software service; identify a particular communicationprotocol utilized in the data traffic; parse the data traffic, accordingto the identified particular communication protocol, to identify aparticular request of the particular software service sent from theparticular software component; parse the data traffic, according to theidentified particular communication protocol, to identify a response tothe particular request sent from the particular software service to theparticular software component; and generate a virtual service model ofthe particular software service from the identified particular requestand identified response to the request.
 21. The system of claim 20,wherein monitoring data traffic comprises receiving transactioninformation captured by a component intercepting requests intended forand responses sent by the particular software service.
 22. The system ofclaim 21, wherein the component is communicatively coupled between theparticular software component and the particular software service. 23.The system of claim 20, wherein the virtual service model is a firstvirtual service model and the service model generator is further adaptedto: monitor second data traffic involving another software service;identify a request of the other software service; identify a responsefrom the other software service; and generate a second virtual servicemodel of the other software service from the request of the othersoftware service and the response from the other software service. 24.The system of claim 20, wherein a particular transaction comprises theparticular request and the response, and the system further comprises arequest processing module adapted to: receive, from a requestingsoftware component, a second request of the particular software service;identify, from the virtual service model, the particular transaction;and return, to the requesting software component, a modeled responsebased on the particular transaction identified from the virtual servicemodel.
 25. The system of claim 24, wherein the modeled responsecomprises at least a portion of the response to the particular request.26. The system of claim 20, wherein the service model generatorcomprises configuration information identifying structure of requestsand responses for each of a plurality of communication protocolsincluding the particular communication protocol.